Implementation of a Parametrised Reduced Functional#241
Implementation of a Parametrised Reduced Functional#241divijghose wants to merge 7 commits intodolfin-adjoint:masterfrom
Conversation
…educedFunctional` where parameters can be updated but are not included in the derivative calculations: 1. Adds a `parameter_update` method 2. Parameters are appended at the end of the list of optimization controls, so `derivative_components` is not a required argument. 3. The `derivative` method returns only derivative corresponding to optimization controls.
|
In the current implementation prf = ParameterisedReducedFunctional(functional, user_controls, parameters)
assert len(prf.controls) == len(user_controls) + len(parameters)This will also be a problem later because the optimisers will expect: len(prf.derivative()) == len(prf.controls)when you will actually have (correctly): len(prf.derivative()) == len(prf.user_controls)If this is the case then you may need to override the To get around this, you may have to instead inherit from the |
…e abstract base class
|
In this intermediate implementation, the However, a lot of the code is duplicated, and, as @colinjcotter suggested, a more efficient way to do this would be to call |
…dFunctional` internally: - Instead of inheriting the `AbstractReducedFunctional` or `ReducedFunctional` classes, `ParametrisedReducedFunctional` simply calls a `ReducedFunctional` object internally and passes the controls and parameters together as `all_controls`
`ParametrisedReducedFunctional` must be a subclass of `AbstractReducedFunctional` Co-authored-by: Josh Hope-Collins <jhc.jss@gmail.com>
pyadjoint/reduced_functional.py
Outdated
| self._controls = Enlist(controls) | ||
| self._parameters = Enlist(parameters) | ||
| self.n_opt = len(self._controls) | ||
| self.derivative_components = tuple(range(self.n_opt)) # Tuple of indices corresponding to optimization controls which are included in derivative calculations. |
There was a problem hiding this comment.
I suspect that you actually want to ignore this kwarg to the internal ReducedFunctional completely because the ParameterisedReducedFunctional is assuming control of the masking logic.
I think the aim would be to remove derivative_components from the ReducedFunctional interface completely once ParameterisedReducedFunctional is merged because it would be redundant.
There was a problem hiding this comment.
I agree that derivative_components is redundant, but since we're passing all_controls (controls + parameters) to ReducedFunctional, can we ignore the kwarg? This implementation shifts the effort from the user to the internal logic.
There was a problem hiding this comment.
I don't think you want users passing derivative_components to ParameterisedReducedFunctional, and the ParameterisedReducedFunctional won't return the derivative values corresponding to parameters returned by the internal ReducedFunctional anyway so there isn't any point in it zero-ing out those components.
It would be a good test of whether derivative_components can be removed if ParameterisedReducedFunctional works without relying on derivative_components itself.
There was a problem hiding this comment.
That makes sense.
There is also a difference between how derivatives are returned:
ReducedFunctional with derivative_components returns
[<dControl1>, <dControl2>, ... , <dControln>, 0, 0, ... , 0]while ParametrisedReducedFunctional returns
[<dControl1>, <dControl2>, ... , <dControln>]Do you think that would make a difference as far as the user is concerned?
There was a problem hiding this comment.
I would not expect it to make a difference because, as far as I am aware, derivative_components is only used as a stop-gap for ParameterisedReducedFunctional.
But actually removing derivative_components from ReducedFunctional is a job for further down the line so we can have a deeper think about whether there is any difference before then, this is just about the ParameterisedReducedFunctional impl.
…h component of the parameter list must first be wrapped in `Control`.
2 participants
Current method to use parameters
The
derivative_componentsoptional argument ofReducedFunctionalis used after adding parameters to the list of controls, to specify which components are to be zeroed out (by omitting them fromderivative_components). This allows the user to update parameters by calling the Reduced Functional while zeroing out the gradient with respect to the parameters.Parametrised Reduced Functional
ParametrisedReducedFunctionalis a subclass ofReducedFunctionalwith wrappingcallandderivativemethods, with the parameters as attributes. Theparameter_updatemethod is called to update parameters. The parameters are not included in the derivative calculation and the optional argumentderivative_componentsis not required.